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TESTER WITH IND£P£I«>£NT CONTROL OF DEVICES UNDER TEST 
Technigfll IWeifl 

This mvention relates to testing of integrated circuits and more particularly to a tester providing 
independent control of devices under test 

S Background Art 

In order to achieve higher reliability, manu&cturers frequently employ **bum-in" testing to accelerate 
potential feilure mechanisnis. The tests are intended to weed out those parts diat may be subject to infant 
mortality. Manufacturers typically utilize higher than normal supply voltages and tenqjeratures during such 
tests and lower than normal frequencies. Bum-in testing normally tests the devices over long periods at the 

10 higher than normal voltages and ten:5}eratures. For some devices, such as current microprocessors (e.g., the 
Athlon**^ microprocessor available from Advanced Micro Devices, Inc.) tiie large number of transistors results 
in high power consun^tion during bnm-in testing. That is m part due to the &ct that CMOS transistors 
typically utilized in such microprocessors leak a small amount of current even when "ofiF*. Because of the 
large number of transistors found in current devices, even if the leakage current of each transistor is small, the 

1 5 cumulative leakage current can be significant. In addition, tiiere is a tendency for tiie faster parts to have 
higher leakage currents. 

Another problem that is &ced when testing high density devices in a bum-in envuronment is that 
operating the device at higher voltage and ten^eratures can result in the device operating in a region in which 
device operation is unstable. More particularly, the device under test can enter a destructive positive feedback 
20 loop in which, as the part heats up, the transistors leak more current, which causes more heat, potentially 
resulting m thermal runaway. Thermal runaway can result in melting the socket in which the device is being 
tested, damage to tiie test board or damage to the device under test. 

Many previous bum-in testers utilized air or oil manifolds to drive all the devices under test to tiie 
same temperature. Thus, no independent temperature control is possible and only limited action can be taken 
25 in response to unstable device operation. Prior art bum-in testers also required tiiat the key parameters, such as 
voltage fiequency or test patterns being applied to die devices under test, be the same for all devices. While 
tiiat may be sufficient for testing older technologies, it &ils to allow the flexibility to test devices according to 
die unique testing parameters that may be required by the individual devices, especially in current bum-in test 
envu?oiuiients. 

30 Thus, it would be desirable to provide a tester tiiat allows the key testing parameters to be varied for 

each device without afiTecting the odier devices under test 

DISCLOSURE OF INVENTION 

Accordingly, die invention provides a tester that provides independent control of die devices under 
test The various operatmg parameters such as ten^jerature, voltage, frequency of operation or test pattern 
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being applied can be independenfly changed on one device without affecting tiie operating parameters of the 
ofbsr devices. Thus, e.g., the amount of cooling or heating applied to one device is independent of the amount 
of cooling or heating applied to another device. In addition, the testing being done on each device may be 
independently controlled. Thus, a test can be changed on one oftfae devices under test wi&out affecting the 
5 tests being run on any of the other devices. Similarly, the voltage and frequency of operation can be controlled 
independently to allow for changes to tibe voltage and/or frequency of one device without affecting that 
parameters on tests being run on other devices. 

In one embodiment, the invention provides an integrated circuit tester that includes a plurality of test 
positions and a plurality of independently controllable tenq^erature control devices associated with respective 

10 ones of the test positions, for controlling a temperature of a device under test at a respective one of the test 
positions. Each tenoperature control device is controlled without affecting operation of the other tenqperature 
control devices. Thus, cooling to one device can be increased while the testing temperature of the o&er devices 
remain constant In an embodiment, in addition, the operating frequency of each of the devices under test is 
independently controllable. In addition, the integrated circuit tester may also include a plurality of 

IS independently controllable voltage regulator drcuits associated with respective ones of the test positions. Each 
of the voltage regulator circuits supplies a controllable voltage to a respective one of the devices under test. In 
addition, fbs integrated circuit tester may also be capable of changing tests being run on one device under test 
independentiy of tests being run on other devices under test Thus, one device can be running a built in self 
test while another device may be being tested with random scan patterns. 

20 In another embodiment the invention provides a bum-in tester that includes a plurality of test stations 

whereia the bum-in tester is operable to independently control temperature of each device under test at each 
test station. In an embodiment, the bum-in tester includes multiple cooling devices per station. 

In another embodiment the invention provides a method of testing a plurality of integrated circuits 
tiiat includes simultaneously testing the integrated circuits at a respective plurality of test positions; and 

25 independently controlling tiie testing temperature of each of the integrated circuits being tested at respective 
ones of tiie test positions. The method may further include independently controlling tiie operating frequency 
of each of the mtegrated drcuits, thereby allowmg the mtegrated cncuits to be simultaneously tested at 
different frequencies. The method may further include independentiy controlling the voltage being supplied to 
the integrated circuits being tested, thereby allowing the integrated circuits to be simultaneously tested at 

30 different voltages. The method may finther include changing a test running on one of the integrated circuits 
without affecting tests being run on others of the integrated circuits. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention may be better understood, and its numerous objects, features, and advantages 
made apparent to those skilled in tiie art by referencing the accon^anying drawings wherein the use of the 
35 same reference symbols in different drawings indicates similar or identical items. 



V 
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Fig. 1 is a high level illustration of an exen^laiy tester that can achieve independent control of 
relevant operational pararaeters for the device under test 

Fig. 2 illustrates die network coupling between each tray and tiie controller shown in Fig. 1. 

Fig. 3 illustrates a block diagram of a tray containing 10 test stations utilized in the tester of Fig. 2. 

Fig. 4 shows an exeniplary high level block diagram of test controller 301 shown in Fig. 3. 

Figs. 5A-5C illustrate exen^lary I^C port register defimitions used m test controller 301 . 

Fig. 6A illustrates an exemplary control register for scan/debug controller 416 shown in Fig. 4. 

Fig. 6B illustrates a scan read register of scan/debug controller 416 shown in Fig. 4. 

Fig. 6C illustrates a scan write register of scan/debug controller 416 shown in Fig. 4. 

Fig. 6D illustrates an exemplary status register in the scan/debug port controller 416. 

Fig. 7 shows an exen:q)lary high level block diagram of one portion of a tray that supports one test 

station. 

Fig. 8 illustrates exen^lary active and passive thermal control capabilities of the tester illustrated 

herein. 

Fig. 9 illustrates an exeiiq>lary user inter&ce for tiie bum-m tester. 

Fig. 10 illustrates a cell host configuration dialog screen. 

Fig. 1 1 illustrates a site host setting dialog screen. 

Fig. 12 illustrates an exen^lary pop-up password dialog. 

Fig. 13 illustrates an exen^lary maintenance dialog screen. 

Fig. 14 illustrates an exemplary high level software architecture for the cell host. 

Fig. 15 illustrates an overview of an exen^lary test configuration stmcture. 

Fig. 16 illustrates an exemplary logic flow diagram for API environmental methods. 

Fig. 17 illustrates an exemplary object stracture of the software operating on test control board 301 . 
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MODELS) FOR CARRYING OUT THE INVENTION 

A high level iUustiation of an exeiiq>laiy tester that can achieve independent control of the operational 
parameters such as teniperature, clock frequency, voltage and test pattern being qyplied to a device under test 
(DUT) is illustrated in Fig, L Bum-in tester 100 includes a plurality of trays 101. In an exemplary 

5 embodiment, each of the trays can test \xp to 10 devices at one time. In the illustrated embodiment, tester 100 
includes 18 trays 101 and fhas can test 180 devices at one time. Overall control of the tester is provided by 
tester controller 102. In one embodiment; the tester shown is lefezred to as a cell and the test contiolla: 102 is 
referred to as a cell host Cell host 102 runs the test sequence for each device being tested in trays 101. Thus, 
cell host 102 controls the testing in all 18 trays. In an exen:q)lary embodiment, as illustrated in Fig. 2, cell host 

10 102 communicates via a network link 201 such as an Ethernet link with each tray. The cell host also provides 
a graphical user interface for control of tests and trays via display 104 as described further herein. 

In an embodiment a site host (not shown in Fig. 1) is coiqiled to multiple cell hosts m order to collect 
test data from die individual cell hosts. The site host congresses the test data, e.g., into a zip file, and places 
die data onto a central server via an FTP connection over a higih bandwiddi connection such as an ISDN line. 

15 Test vectors and/or test sequences are downloaded via Etomet link 201 to specify to each tray the 

tests to run on the devices being tested. As shown in Fig. 3, in one embodiment each tray includes a tray 
control board 301 that controls testing on five device test boards 303. The device test boards 303 are coi^led 
to the tiay control board 301 through inter&ces 3 10 and via an Inter-IC (I^C) interface, which is a multimaster 
two wire serial bus. Test conditions for the device test board 303 such as temperature, voltage, and jfrequency 

20 are set via the bus. Test patterns that are applied to each DUT such as BIST, SCAN, or other JTAG initialed 
test come across interface 3 10. In the particular embodiment illustrated, each of the device test boards 303 
includes test positions for two devices under test Other embodiments may provide for more or fewer test 
positions on each device test board 303. Thus, each tray can simultaneously test 10 devices. The tray control 
board 301 includes a processor 31 1, a flash memory 313, a power supply 315 and a network interface 317. 

25 Flash memory 313 stores the tray control program. The tray control board 301 receives commands from cell 
host 102 (Fig. 1) and sends test results back to cell host 102. The commands may include test vectors that are 
processed by tray control board 301 and then supplied to the device test board and the device under test 
Having a single control board and multiple test boards provides flexibility in that the tester can be reconfigured 
to accommodate new device test boards 303 and as the devices under test change and/or are iqxlated. Note 

30 that the number and type of mter&ces between control board 301 and device test boards may vary accordmg to 
system requirements. 

Referring to Fig. 4, the tray control board 301 is shown in greater detail. The embodiment shown in 
Fig. 4 is illustrative. Tray control board 301 kcludes Ediemet controller 317, which coi^les to the Ethernet 
link 201 that couples to the cell host The tray control board 301 includes a local I^C bus 402. The tray 
35 control board includes multiple conq)onents that are software accessible and are described below. 

There are tiuree 1^0 ports on the local test controller I^C bus 402 used to access various features 
described below. They are connected directly to I^C controller 412, which m one embodiment is a PCF8584 
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controller manufactured by Phillips Corporation and which is coupled to ISA bus 404. The I^C port 
register definitions are shown in Figs. 5A-5C, and in one embodiment, the ports reside at address 20h, 21h and 
22h, where h represents hexadecimal. Bits (7:4) of port 20h control firont panel LEDs. Bits (2:0) (I^C Sel) 
select which test board 301 is tiie target The fC bus is also routed to each of the individual test board 301. 
5 The I^C port de-multiplexer circuit 406 is used to select in hardware which of the tray test boards receives a 
particular communication. Thus, all device test boards can be accessed via a write to I^C bus 402. The fliree 
ports 407, 408, and 409 correspond to the port register definitions shown in Figs. 5A-5C. Bit 3 of port 20h is 
an output enable bit for communicating with the I^C buses on the device test boards 303. I^C ports 408 and 
409 control debug LEDs 410, The LEDs are controlled through ports 21h and 22h as shown in Figs. 5B and 

10 SC. The tray control board also includes a system monitor 425 such as a Winbond W83782D that monitors 
local system events. For example, it monitors DC voltages of 3.3 volts, 5 volts, 12 volts, microcontroller 3 1 1 
battery backtqp voltage, speed of the two chassis &ns and a tray switch. The system montior 425 can generate 
an interrupt (PIRQ2) on the SMI pin when there is a problem detected with any of the voltage ii^uts, chassis 
fans, or when the tray is opened. A ten^erature sensor 414 is used to monitor the anibient temperature of the 

15 chassis and, in one embodiment, is an LM75 provided by National Semiconductor Corporation. In one 

embodiment die tray control board 301 provides a connection to which a debug card containing seven segment 
LED displays can be plugged into whidh can be used for debugging software and hardware problems. . The 
port 80-/84 LEDs are shown as 420 in Fig. 4. 

A scan debug port controller 416 provides the link between microcontroller 311 and the devices under 
20 test on the device test board 303, In one embodiment the scan debug port controller is a field programmable 
gate array (FPGA) which resides on the VL local bus 405 of microcontroller 311. Microcontroller 311 is the 
main controller on the tray control board 301. In one embodiment the microcontroller is an ELANSC400- 
66AC system controller provided by Advanced Micro Devices. In an embodiment the microcontroller 311 
utilizes 16 MB DRAM 421, and 512 Kbytes of Flash memory 313. An internal serial port 423 comiects to an 
25 external debug system. As shown in Fig. 4, die microcontroller provides for connection to an ISA bus 404 and 
a VL bus 405. In one embodiment microcontroller 311 can program the field programmable gate array 416 by 
programming FPGA ROM 422 through general purpose I/O pins 424. 

The scan/debug controller 416 controls the scan and debug port operations for the device under test 
In an exemplary embodiment, scan/debug controller 416 includes eleven 32 bit control registers, one for each 

30 of the ten individual devices under test controlled by the tray controller 30 1 . An additional 32 bit control 
register provides the capability of writing to all ten control registers simultaneously. That capability is also 
referred to herein as gang mode operations. The control registers provide setup for the various control bits 
required for debug port and scan operations. Because those functions vary depending i^on the device under 
test, the particular fields in the control registers will vary accordii^ to the capabilities and reqmrements of die 

35 devices tiiat are tested by the bum-in tester. 



An exenq}lary set of control fimctions are shown in Fig. 6A and described below. Scan control field 
in bits 1:0 in one embodiment control test pms on a device under test Certain devices may include special 
circuits tiiat are sensitive to scan patterns in that scan patterns can place those circuits in an mtemal contention 
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state in the device under test The scan control bits [1 :6] configure the test pins to allow such special circuits 
to be shielded from random scan patterns or other hannfiil scan patterns and also to allow selective loading of 
appropriate scan patterns for the special circuits. As just mentioned, in one endbodiment the tester can apply 
landom scan patterns to a device vaadet test Accordingly, a random mode bit (2) is provided in &e control 
S register to selectively enable the random scan noode. A count field in bits 7:3 indicates how many bits to scan 
in to tiie particular device mider test A compare enable bit (8) enables conq)anng of scan-in data and scan-out 
data. A miscon5)are can be programmed to cause an intamxpt to the microcontroll^ 3 1 1 . A scan enable bit 
(9) can be used to enable or disable scan as desired A gang mode bit (10) specifies when the control register 
can be written by writing the eleventh control register. Because the gang mode bit is present in each of the 
10 control registers, a multicast capability is provided by the gang bit to write up to ten of the control register 

simultaneously. Thus, use of the gang control register allows the same test to be applied to one or more of the 
devices under test by writing only the single control register. 

The Scan Clocks 1 and 2, bits 1 1 and 12, are used to cause the respective scan clocks to be pulsed A 
reset bit (13) selectively resets the device under test. A control bit (14) selectively enables an auto Built In 

15 Self Test (BIST) mode in which BIST continually executes on ttie device under test In one embodiment the 
device under test provides an indication when BIST has completed On completion, the controller can detect 
that conq>letion and inmiediately initiate a new BIST. In that way, BIST can continue running. Setting the 
Advance bit (bit 15) generates a single pulse on the clock selected by the ADV/BYP bit, then clears itself. The 
AD V/B YP bit (bit 1 7) defaults to 0, causing the Advance function to be routed to the bypass clock pin of the 

20 DUT. In an embodiment the bypass clock is an alternate test clock input to allow the on-board Phase Locked 
Loop (PLL) normally used to generate clocks to be bypassed. If the ADV/BYP bit is set to one, the bypass 
clock generated by scan controller 416 is routed to &e bypass clock pin.. Setting the Compm Reset (bit 16) 
clears the scan coiiq)are error flag, then clears itself. 

The Bypass Frequency Select bits (20:18) selects the frequency of the bypass clock. The BIST 
25 resume bit (21) resumes the auto BIST function after an auto BIST error condition halts the auto BIST process 
and clears the corresponding AutoBIST IRQ Flag bit in the status register and then clears itself. 

In addition, the control register includes control bits for the JTAG signals, TMS, TCLK, TDI and 
TDO and TRST. These bits are used to control the scan port on the device under test The DBREQ and 
DBRD Y signals are handshake signals respectively requesting and acknowledging entering into a debug mode. 
30 Unique control bits should be provided to exploit the particular debug capabilities of the device under test. 
The test data out (TDO) bits and DBRDY bits are from the DUTs. Note that the particular control bits 
described in relation to Fig. 6A are exenoplary only, and as stated above, will vary depending upon, e,g., the 
capabilities of the device under test and the particular tests tiiat are desired to be run on the bum-in tester. 

In addition to the control registers, the scan debug controller 416 has a scan read and a scan write data 
35 register as shown in Figs. 6B and 6C, for each DUT. The scan read data is data scanned out of the device under 
test and the scan write data register is data to be scanned into the device under test 
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The scan/debqg controller 416 also includes a status register shown in Fig. 6D. The status register 
provides such status information as scan conqjare results (bits [9:0]), one bit for each of the devices under test, 
and intemipt bits [14: 10] from the device test boards. Each bit in a module sense bit field (bits 19: 15) indicate 
whether a device test board is connected to the tray control board in a corresponding slot. A tray switch bit 
5 (20) indicating whether tiie tray in ^ch the test control board 301 and device test boards 303 reside, has an 
open lid. Bits 30:21 indicate which of the ten DUTs had an autoBIST error. 

In addition to particular control bits tiiat are used to control each of the devices under test, general 
purpose control registers provide for enabling of interrupts, control of power, including povror-down of all test 
modules smmltaneously, control of clocks, and reset capability of the system controller and tiie f C controller. 
10 Note that some devices under test, particularly microprocessors have the capability to multiply a received 
clock according to software or pin programmable clock multipliers. In such an embodiment, appropriate 
control is provided to support such capability. 

The cell host supplies the particular test through the Ethernet controller to microcontroller 311, which 
dien writes to tiie appropriate control register m the scan/debug port controller 416 to cause the test to be 

15 appHed to the DUT. The tests supplied by the cell host sj^cify all tilie information that is required for the tray 
control board 301 to cause the test to be run on devices under test on the device test boards 303. Some test 
parameters may be set up via the fC bus. The test information specifies voltage levels, firequency levels, the 
type of test to be run, for example, whether BIST is to be run or a scan test is to be run. And if a scan test is to 
be run, the scan patterns are provided through Ethernet controller 3 17 over ISA bus 404 to microcontroller 

20 311, and subsequently to the scan write registers in scan/debug port controller 416. The clock, voltage and 

cooling control information is supplied in the embodiment described over the I^C bus to the device test boards. 
Thus, the instructions from the cell host may specify a voltage level for the device under test. That 
information is communicated to the microcontroller 311, which then writes tiie appropriate information via the 
bus to the device test module through I^C port 406. 

25 An exen^lary bum-in tester according to an embodiment of die iavention meets the foUowiag 

electrical capabilities. Each device under power is assumed to be capable of 1-33 watts of power consuniption 
that includes 1-15 amps at 1.5-2.2 volts. The clock that is supplied to the devices under test ranges from 
1-200 MHz. In an exemplary embodiment, tiie bum-in tester atten^ts to achieve more than 95 percent node 
toggle coverage. The bum-in test patterns that are applied to the device under test includes built-in self-test 

30 (BIST) capabihty in the device imder test That BIST capability may include, e.g., memory tests for memory 
located in the device under test As previously mentioned, the bum-in test patterns may also include random 
serial scans. In addition to random serial scans, scan patterns from production testing can be adapted to run on 
the bum-in tester. Test patterns may also include fimctional testing as well. For example, if a microprocessor 
is the device under test, the processor may execute code as a functional test of die device. That may be 

35 acconq)lished by loading cache memory via a scan interface such as a JTAG port or other appropriate debug 
inter&ce. 
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While tiie tests are running, the bum-in tester monitors whe&er the tests conaplete without failure. 
Blending on the type of test pattern being applied, that can be determined from pass/fail signal STq)plied by 
Hhs device under test or by monitoiing an internal register via a scan interface or monitonng a signal provided 
by the DUT. A test may also require a conoparison of scan data scanned out of the device under test to 
e:q)ected results. It is also desirable for the bum-in tester to log data indicative of the tests run on the device 
under test Such test data typically includes the date, time, and event, including any &ihires, along with 
sufficient information to identify tiiie device under test Such information may include lot, test position, along 
with tester information such as serial number of die test control boards and device test boards as well as 
revision numbers for e.g., the control software. 

Because of the large number of transistors and high leakage current typical in state of die art devices, 
the bum-in tester in an embodiment provides both external heat for low leakage parts and cooling to stabilize 
high leakage parts. In a preferred embodiment, the bum-in tester provides active feedback on a desired 
tenaperature for testing, e.g., to set the operating ten^erature for testing at 130**C. In addition, there is 
preferably temperature monitoring. As described further herein, die thermal requirements can require both a 
Peltier device and a fan at each of die test positions in the tester. Because of the variations in power diss^}ated 
at ten^eratures involved in the testing, it may be preferable to have a direct contact thermal solution. Use of 
an active cooling device, e.g., a Peltier device, ensures that the bum-in tester has programmsible thermal 
control over individual DUTs. The bum-in tester also preferably provides a mechanism that allows quick, 
easy access to change the DUTs. 

An exen^jlaryhigh-levelblockdiagramof one portion 701 of a device test board 303 is shown in Fig. 
7. The one portion 701 supports one of the DUTs, e.g., 305, shown in Fig. 3. The illustrated portion m Fig. 7 
includes a socket 702 for receiving the device under test 704. In one embodiment of the invention, the device 
under test is a microprocessor. For ease of wiring the test board in one embodiment, many of the processor 
pins are not connected. Only those pins that are required to implement the required bum-in tests are 
connected. In other ernbodiments, all of the puis of the device under test may be connected. The portion 701 
of device test board 303 also includes a voltage regulator 703 sillying programmable voltage to the device 
under test and a clock generator 707 supplymg programmable clocks to the device under test In an 
embodiment, programmable clock multiplier values are supplied to the processor as another control 
mechanism for the frequency of the microprocessor clocks. Cooling devices are provided to cool ttie device 
under test. A fan (not shown) can be controlled via a system monitor 709. System monitor 709, which may 
be, e.g., a Winbond H/W Monitoring IC W83782D, available from Winbond Electronics Corp., can also be 
used to control the voltage regulator, monitor tenqperature and provide appropriate fan control signals. In 
addition to the fiui, die illustrated embodiment includes a diem^oelectric cooler (TEC) device 708 that can also 
be controlled via system monitor 709. The voltage being applied to the TEC can be changed to regulate the 
amount of heating or cooling. In an embodiment, the mode of TEC operations can be switched between off 
and full cool to achieve better diermal stabilizatioiL In another embodiment, the TEC can be switched from 
full heat to full cool mode. 
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Various status and control infonnation may be communicated to and J&om the various functions 
described in Fig. 5 using an I^C bus. Other serial or parallel buses may also be used according to system 
requirements. Jn addition, appropriate logic may be used to translate from the fc bus to another data format 
when necessary. 

5 Exen5)lary active and passive thermal control capabilities are illustrated in Fig. 8. Device under test 

801 is coupled via thermal shmit 802 to a thermoelectric device (TEC) 803. TEC 803 is activated to provide 
cooling to the device under test. In addition heatsiok 805 is coiq)led to draw heat away horn DUT 801 and 
TEC 803. Fan 807 provides fur&ercoolmgcapabihty. 

In one embodiment, a tenq}erature sensor, e.g., embedded in a heat sink is used to determine tiie 
10 tenqserature of the device under test. In other embodiments, the device under test may itself provide a 

ten^erature sensor that can be read by an external device such as system monitoring chip 709. Because two 
devices are tested on each board 303 in the illustrated embodiment, tiie logic described in Fig.7 is duplicated to 
the extent necessary to provide indq)endent control over each device under test While the control may be 
completely duplicated, lesser amounts of independent control may still be sufGcient For example, clocks may 
15 be supplied commonly to both devices under test. That is in part because clock control unique to a DUT can 
be achieved usmg clock multiplier values provided to a microprocessor being tested. 

The tiay control board 301 individually controls each of the trays and each of the devices on the 
individual test boards. The status on the teniperature of each DUT is fed back to die tray control board 301 
and subsequendy back to the cell host Software running in the cell host can check the temperature at each 
20 station at a programmable interval to monitor ten:5)erature stability. The cell host can, if necessary to achieve 
stabihty, request an appropriate combination of a different test sequence, voltage, frequency, or additional 
cooling capability, e.g., turning on both the fan and TEC for a greater portion of the testing to try and achieve 
thermal stability as described more fully herein. 

As previously described with relation to Fig, 1, an interface is provided through display 1 04 for the 
25 cell host operator to utilize the exemplary tester 100. Referring to Fig. 9, the operator interface contains all the 
controls that the test operator needs to utilize the tester. 

The control pad 901 is utilized by the operator to enter a logon ID, a lot number, and to select the 
device ID. The status window 903 provides tray status information. In addition a CPU status window, CPU 
buttons, and the maintenance button are provided. The racks (rack A, rack B and rack C) correspond to the 
30 hardware racks shown in Fig. 1 and hold the trays. The trays in the main object show run time status, alerts, 
starts and stops of testing, and shows elapsed time and remausing time. 

A dynamic add tray window will be displayed when a tray, whose IP address has not already been 
listed in the P list tries to connect to flie cell host That window contains three lists of trays, one list for each 
rack. The engineer who adds the tcay will be pronq)ted to select a location for die new tray to be added (i.e., in 
35 which a specific rack in which sequential location). When a new tray is added, a version check will be done 
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on the version of the embedded software in the tray. The version that is returned needs to be the expected 
revision or greater, othraivise a message box will indicate software needs i^dating. 

A number of buttons in die user inteiface are password protected. The password protection 
segregates engineering activity, such as providing a new test, from actual testing activity. For exairqple, tiie 
5 close button, when activated, pronqjts for a password before aDowing the closing of the cell host The rack 
configuration button 906 is a password-protected button ftiat allows software updates and other configurable 
parameters to be changed per cell host. The maintenance button 908 is password protected and pops vtp the 
maintenance dialog when pushed. 

During bum-in, the lot number is an important information conq>onent of the bum-in process. The 
1 0 test start button will not work, i.e., testing does not start without a lot nuniber. After entering the lot number, 
the operator presses the lot number button. The operator is then prompted to select the racks that contain this 
lot, which is done by pressing the button on top of each rack, i.e., **Rack A" '"Rack B" or '"Rack C". 

The "Program Rack (A, B, or C)" field provides for selection of the type of the device that will be 
inserted into the mcks for bum-in. That identification is used to look up the names of the test configuration 
15 file that will be used to perform the testing. 

The tray status area 905 displays information about the tray's general status. The type of information 
that is displayed can include rack number, tray number, tray IP, CPU pass/fail/en^ty/not active state for all ten 
devices under test in that particular tray. The CPU status window in status window 903 provides detailed 
status information for the selected device under test. In order to show information in that status box, 1h.e 
20 operator selects a specific CPU after selecting the specific tray. The data that will be displayed for this 

selected CPU mimics the data that is being written to a status file. Displayed data thus will be a snapshot of 
the data to be logged before ftiR tray button is pressed. 

The tray button 907 is used to indicate alert information to the user and allow the operator to select 
which tray to get detailed status information. The tray button 907 can color encode information. Thus, one 
25 color can be used to mdicate normal operation. Another color, such as red, can indicate that one or more of the 
processors have failed during a particular bum-in cycle. Anotiier color can indicate tiiat the tray is ready for 
unloading. Anotiier indication can be used to indicate that tiie tray has been disabled. 

A start/stop button, shown as the "Off" button in Fig. 9, starts the testing of the parts in tiie tray. Once 
the button has been pressed, the text on the button changes to stop and the button color will turn to, e.g., red to 
30 indicate the stop function. Pressing tiie button again causes the testing to stop, the buttons tum back to green 
and the text to "start" In addition, a tray nnay be pulled out When that happens, a tray switch triggers and 
testing is paused. If the tray is pushed back in, the testing will continue. The operator presses the stop button 
and testing will be terminated and the button will return to the start state. The timer display shows the elapsed 
time of testing. 



wo 02/054094 



PCT/USOl/17591 



-11 - 

Referring to Fig. 10, a cell host configuration dialog is illustrated The cell host configuration dialog 
is accessed via tfie password-protected button 906 labeled configuration in Fig 9. That dialog allows engineers 
to change the settings of the cell host that point to different databases and odier data files. Fiessmg buttons 
that are password protected in the cell host dialog, causes a popup password window such as shown in Fig. 12. 
5 That window will stay i^untU the correct password is input Referring again to Fig. 10, the host to tray IP 
field 1001 is an P entry field giving the internet protocol address tiiat the cell host uses to talk to the trays. 
The cell-to-site host IP field 1003 is also an IP entry field that defines the IP that the ceU host should use to 
connect to the site host The root status directory 1005 designates the local directory where the status data files 
are stored. 

10 The software download section 1004 provides the ability to the embedded sofiware on the test 

control board. There are three separate pieces of software that can be updated. The first one is the "cluster** 
program which is the main control program for control board 301 and is loaded into flash memory 3 13 (see 
Fig. 4). The location of the image can be specified in the cluster image field 1006. The second portion of 
software that can be loaded is BIOS ROM 430 shown in Fig. 4, which can be specified in BIOS ROM image 

15 1008. The BIOS ROM is used to booti^» file control board 301. The last piece ofsoflware that can be 

iq)dated is software defining the functions for tiie scan debug controller 416, which can be specified in field 
1010. 

The save button 1007 saves the settings that have been entered or changed on the cell host 
configuration window. The cancel button 1009 ignores any changes that have made it to the entry fields on the 

20 cell host configuration window and closes the wmdow. The site host settings button 1011 pops up a window 
that allows additional configurability to the cell host Specifically, it allows the pomters to the site host 
information to be altered so that the cell can be severed from communicating with the site host Referring to 
Fig. 1 1, the site settings dialog is illustrated. The site setting file field 1101 specifies the name of the site 
settings file. The c%.db field 1 103 provides the path to the configuration database that contains the list of test 

25 configuration files and what device identifications map to the test configuration files. The save button 1 1 04 
saves the data ^t was changed by the engineer. The cancel 1 105 button ignores the changes that the engineer 
may have made and the update button causes the site setting and configuration files to be updated and their 
contents registered. 

Referring again to Fig. 10, the about button 1013 pops up an about box providing the version 
30 information for the cell host program. The site host settings dialog is accessed via the password protected 

button 101 1 labeled site settings on the configuration dialog shown in Fig 10. The site setting's configuration 
allows engineers to change the names of the files that the cell host uses to configure its communications with 
the site host 

In addition new tests can be added by an engmeer. In an embodunent, a dialog pops up fhzt allows an 
35 engineer to install a new test into tb.t cell host Use of tiie dialog generates the needed registry entries for die 
test to be used. The dialog includes a simple file selection edit field tirnt allows the engineer to pomt to the 
new file/test to be added. An add button in the dialog can be used once the file/test has been selected. 
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Referring to Fig. 13 an exen5)lary maintenance window is shown. The maintenance window is 
accessed via the password protected maintenance button. That window allows an engineer to view the 
m a intenanc e statistics, as well as reset the settings after a socket or individual test board has been replaced. In 
addition, whole trays can be maiked as bad and later remarked as good. Note that if a new tiay is inserted into 
5 the position of^ere a bad tray was indicated, the new tray position will automatically be maiked as good. 

A tray maintenance file can store maintenance statistical infonnation for each tray that exists within a 
cell The type of information that is tracked per tray includes the cell number, tiie rack number, the tray 
number, the last update, tiie cell host version, the cluster version, ^ BIOSROM version, the IP address, the 
number of fails, passes, inserts, powers, auto shutdowns, manual shutdowns, socket state. 

10 The user interface thus allows tests that have been configured for a particular device under test to be 

applied by an operator of the tester to the devices under test. The various screen shots shown in Figs. 9-13 are 
exenq>lary only. The type of user interface is dependent on system design and capabilities. 

An exen^lary high level software structure for the cell host is illustrated in Fig. 14. The major 
objects of an illustrative cell host includes a tray object 1401 for each tray controlled by the cell host A 
15 separate £themet object 1403 is instantiated for each tray object 1401 so that each tray object can 
independently communicate with its corresponding tray. In addition each tray has an Application 
Programmmg Interface (API) object 1405 and ActiveX controls 1407 definmg the tests that can be run. The 
API object 1405 is used to send commands down to the test control board to perform testing on devices on the 
device test boards. 

20 The cell host software communicates with the trays via a rack port, which is accessed through 

Ethernet object 1403 in Fig. 14. The cell host has one thread listening for incoming test board connections. 
When a connection is requested, it will spawn a &iead to handle the actual request and the original request will 
continue to listen for more incoming connections. The site host operates in a similar fashion to the cell host in 
that it has a single listening thread and spawns multiple threads to handle incoming requests fix>m cell hosts. 

25 Each cell host requests a connection to send its data to the site host after each bum-in period has completed. 

As shown m Fig 14, a tray thread is created for each tray that populates a rack. Testmg is 
accoa5)lished by writing a test program that is loaded during run time based on the test operator's selection of 
device type through the user interfiice illustrated in Fig. 9. In one embodiment, the test program is generated 
and corq)iled using Visual C-H-. Providing a compiled test program has advantages in that the test program is 

30 free from potentially being modified by unauthorized people. In addition, the program that was released 

cannot be modified at run time or at the cell host Further, better performance is achieved by running compiled 
code as con^ared to running interpreted code because tilie interpretation step is already con^leted. Thus, the 
commands for ^ecuting the test can be sent down to the tray immediately. The tests are provided through an 
appHcation programming interfece (API), which in an embodiment, are inqjlemented with ActiveX controls 

35 using con^onent object module (COM) technology from Microsoft Corporation. 
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Referring to Fig. 15, an overview of the test configuration is shown. Each cell host includes a tray 
window object T^yWnd 1503 that inteifeces to tiie APIs 1507. Note that Fig. 14 shows Tray 1401 as a 
graphical represemtatioii of TrayWnd 1503, which is an actual code object. Also, API 1507 is the 
inq)lementationofthe logical definition API 1405. The cell host application^ protected at 1505 fiom process 
5 failure comqttion. That nieans timt the tray window thread remains numing even if tiie process dies. The 
APIs 1507 provide test functionality through interfaces 1509, tiie test functionality residing in dynamic link 
library (DLL) 1511, which contains a library of executable test functions described further herein. The class 
CtesfThread 1513 shows that a separate test thread is kicked off for each instance of a test invoked through the 
inter&ces. Fig. 15 shows the Itest interface separately from the other inter&ces 1509 because Itest needs to be 
1 0 iiiq>lementBd by the test so that the test thread knows how to communicate with the test 

Providing test functionality through APIs is advantageous because it abstracts test functions away 
firom the test writer. Modifications to the APIs to reflect additional test capability of DUT can be made 
without affecting the tests already writtea. There are several generic definitions that can be used with multiple 
ones of the API functions. For exaicple, a MODULE-ALL definition can be used to apply the function 
15 utilizing that definition across all of the devices imder test in the tray. The CPU-ALL definition applies the 
function on both the devices under test in a single device test board. QUERY can be passed as the out or retum 
parameter to any functions that have such parameters. 

The interfaces 1509, illustrated in Fig. 15, include timing, environment, logging, debug port, scan, 
hos^ and JTAG. Each of the inter&ces shown in Fig. 15, ITming, lEnvironment, ILogging, IDebug port, 

20 IScan, IHost, and I JTAG include a variety of functions that allow a test to be written by invoking those 

functions. Various test functions are defined to pass tests and results to and from the various test boards. For 
exan^le, tray events functions transfer unexpected packets from the tray back to the test program to signal that 
some kind of event has occurred in the tray. That may be due to an API event failing or a problem with the 
hardware being detected by tiie imbedded software in the test control board A parameter is provided that 

25 pomts to abufiSsr that identifies the packet as a trc^ event, along with the size of the packet, the ID of the 
friiling API, the module number, the CPU number, and the reason for the event 

A tray history function is called rigjit after a test file is loaded. That function has a data stmcture 
passed in it that defines all pf the trays enviroimiental states. If testing is paused, a perform testing function is 
a main routine to which testing code is added. A terminate testing function is called by the tray in the event 

30 tile operator has pressed the stop testing buttoiL A pause testing routine is called if the operator pulls the tray 
out The centime testing routine is used if the operator has pulled the tray out and then pushed it back iiL It is 
the tests responsibility to redo the environment for tiie device under test so valid testing is continued and test 
time is not lost. The tray history function provides the environmental information. A received packet routine 
passes tiie packet through the tray into the API object. Note tiiat exemplary functions are being described. 

35 The specific functions required will vary from tester to tester and depend on the software used to iiiq)lement 
tiie APIs and tiie test programs, the specific capability of the tester and the devices under test 
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The environmental interface, lEnv, includes a plurality of functions that are used to specify the 
enviroxunent in which a test is pexfoimed on a particular device under test For example, a function is provided 
to set (he clock frequency for one of tiie specified modules. In an enibodinien^ ^ function can request that 
file current setting of the clock frequency of die specified module be returned A clock mult^lier function sets 

5 the niuhQ)lier clock fiiequency for the specified module in order to specify the clock fi:equency for fixe device 
under test A power supply functionprovides the capabiHty to power on/off a specific modde/C^ A LED 
Junction allows the LED color for the specified CPU to be set That LED can be used to indicate, e.g., a failed 
test A reset function causes tiie reset pin of a specified device under test to be toggled in order to cause tiie 
device under test to reset A voltage function sets the voltage for a speciQed device under test A fan function 

1 0 allows the tachometer on a specified fan to be set A temperature function provides the ability to read the 

values of various ten:q)erature sensors provided m die device test boards. In addition, a deshed tenq)erature set 
point can be passed to cause die TEC to heat or cool accordingly to try and achieve the desired set point 
Various other functions can be provided to control die envuronment according to the needs of a particular 
system. Note that die functions described herein axe exemplary and will vary according to the types of 

IS environmental parameters that die tester is designed to control. 

A timing mterfrice (TTiming) is provided in interfaces 1509, which provides a pluratity of timers that 
can be used for timed testing tasks. Thus, for example, functions may be provided to start a timer, stop a 
timer, return a value of an elapsed timer, etc. Preferably, a sufficient number of timers are provided so that 
multiple aspects of tests can be timed simultaneously. 

20 A log interface (ILog) is provided in inter&ces 1509 diat allows logging of information to an 

appropriate file. The functions will be unique to the type of log file that is created, e.g., based on the type of 
information logged. For example, a function may provide for writing a header that provides base information 
identifying die source of the data. An add value entry function can be provided that allows an entry to be added 
to a status file. ' 

25 A scan inter&ce (IScan) provides the ability to specify a scan pattern to be scanned into a specified 

CPU. The scan function may provide the ability to specify die pattern to scan in, as well as an expected scan 
out pattern. 

A host mterface (IHost) allows messages to be passed by a test diat will appear on the user inter&ce 
or other designated location so diat the message can be viewed by a test operator. An error log function may 
30 also be provided that allows a message to appear. 

A Joint Test Action Group (JTAG (IEEE 1 1 49. 1 )) mterfece (UTAG) provides die ability to mteract 
widi die JTAG mterface. The functions are heavily dependent on die test capability provided through JTAG 
on the particular BUT. Exenq>lary functions may include a clock control function to provide access to clock 
test modes such as cycle stretching, stopping the phase locked loop (PLL) on a specific cycle or generating N 
35 clock pulses from the PLL. A ring oscillator instruction function allows testing of a ring oscillator internal to 
die device under test A run automatic test pattern generation (ATPG) function configures certain pins as 
scan data inputs and scan data outputs. The function may also allow die DUT to be configured as a single scan 
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chain or nmltq)Ie scan chains to run ATPG pattens. In addition, functions may be provided to configure the 
JTAG to provide access to a manufacturing ID and control various test functions that are available. The 
particular functions will vary depending i^on the type of test capabilities that are provided through the JTAG 
port That will necessarily depend \spon &e device imder test For exan^le^a function can be used to force all 
output and bi-directional pins into a high int^edance state. An instruction can be used to cause the bypass 
legists to connect to Hie test data iiq>ut (TDI) and test data output (TDO) of the JTAG inter&ce. 
Alternatively, an instruction can cause the hardware debug test data register to be connected between TDI and 
TDO. Additional instructions can cause various built in self test routines to be activated and/or get the result 
of success or failure of those routines. Other functions may be defined to put the device under test into specific 
states so specific tests can be performed on them. For exan:q>le, the device under test may need to be 
initialized to a known state using a scan flush operation before a particular test can be performed. 

In addition to JTAG functions, an exemplary tester also provides hardware debug tool ftmctions 
which provides for certain debug capability in a processor such as tiie Athlon™ processor. Any such 
particularized debug capability can be supported by functions provided in the interfaces. 

Odier functions may be provided according to the needs of the particular tester. For exaniple, a utility 
interfece (not shown in Fig. 15) may be provided that can be used to perform utility functions on the test 
control boards and the device test boards. The utility functions may provide, e.g.» the capabihty to modify 
software on the device test board. 

When a test is sent from the cell host to the control board the test is sent in a packet with predefined 
fields. Those fields can then be unpacked and acted on by the control board 301 . Illustrated below are the 
fields of an exen^lary packet: 

Stmct Packet { 

BYTEm^Packetld 
BYTEm PacketSize 
BYTEm"MethodId 
BYTE m_Module 
BYTEm^CPU 
BOOL m^ConfirmFlag 
DWORDln_BufFerSize 

}; 

The Packetid defines whether the packet represents an API request, a tray event, or a Ping event. Hie 
PacketSize defines the number of bytes in the packet The MethodID defines vMch specific API to call. The 
parameters associated witli that MethodID are put into different fields of the packet structure based on the API 
definition. Once the packet has been sent, software operating on the test control board receives the packet, and 
based on tiie Metbodld, extracts the parameters out of the packet and calls the function corresponding to tiie 
MethodID. The module field specifies the device test board and the CPU field specifies ^ch CPU on the 
device test board. The ConfirmFlag indicates whether to send back confirmation on whether the API executed 
success&Uy. Data may acconq>any tiie packet m which case the BufTerSize field specifies die size of 
accoir^anying data. 
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Referring to Fig. 16, an exemplary logic flow for environmental methods is shown. In 1601, an API 
request is organized into a packet such as the exemplary packet shown above. In 1603, the packet is sent to the 
tray via, e.g., an Ethernet link. In 1605, a check is made to see if the packet was sent satisfactorily. If so, then 
a determination is made if the API is a query in 1 607, which means that a retum value is ejected that 

5 provides, e.g., a current tenq>erature or voltage condition in a test board. In addition, if the API does not 
require a response from a tray in 1 609, then Result is defined as okay indicating the API request was 
successful and the API returns to the caller in 1623. Result may be defined to be zero for a successful retum 
fix)m a function and non zero if an error occnrred or if status or response information is returned Note that if a 
response is required, the tray control board may determine the value of the retum code in Result as shown in 

10 1621. If die packet did not fire satisfactorily in 1605, then Result is defined as a failure or a time-out in 1615. 
If &e API is a query or if the API requires a response fiom the tray, then the API waits on a received packet 
flag to go true in 1611. If the waiting in 1611 results in a time out, then Result is defined as a Mure m 1615. 
If die wait did not time out in 1617, then ih& method waits on the pause flag, if the pause flag is true. At the 
end of the pause or if the pause flag is not true, in 1621 the value firom the receive packet is moved to the out 

15 parameter so that the API can retum the parameter, the method defines Result as ok in 1613 and returns to die 
caller. 

On receipt of the packet by the control board, software operates to inclement the testing or other 
action requested in tiie packet sent using the API. That action may involve setting and/or retrieving 
environmental parameters, initiating various scan, BIST or operational testing, updating software or other 
20 action that may be specified in the packet 

The control board 301 implements those functions using a software stmcture illustrated at a high level 
in Fig. 17. As can be seen, the software structure is closely correlated to the hardware stmcture. The major 
objects in the test control board software include an Bthemet object 1701 that provides a connection to the 
cellhost API 1700 is the list of actions that the cell host and test programs use to cause the test control board 

25 software to take specific actions on a device under test or provide environmental control of the test control 
board or device test board. A test control board object is provided to control enviromnental conditions of the 
test control board 301 (Fig. 3). Under the test control board is a system controller 1705 that provides system 
control for ten:Q)erature and fims on the system control board Objects 1707 and 1709 provide hn. and 
tenqjerature monitoring capability, respectively. In addition, a test card object 1711 is provided for each test 

30 device board 303 controlled by the test controller card 301. Eachtestcardin turn has two DUTs 1713. Each 
DUT, in tum, has objects to control LEDs 1715, a system controller object (for fans, voltage, etc.) 1717, a 
TEC control object 1719 and a voltage control object 1721. In addition, a voltage monitor object 1723, a fan 
control object 1725 and a temperature control object 1727 is provided. In one embodiment a clock object is 
instantiated for each test card 171 1 ra&er than for each DUT 1713. That is because there is shared clock 

35 control capability for tiie two DUTs in the illustrated embodiment. In other embodiments, die clock generator 
object may exist for each instance of DUT 1713 reflecting fully independent control of clock generation. 

One ixxq)ortant aspect of the software architecture is that each device test board and each device on 
each test board has separate threads to control environmental conditions such as voltage and tenq)erature. 
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Thus, when a test is iidtiated for a particular device under test in a particular tray, tiiat software operates 
independently of the software controlling the testing on other devices under test That software and hardware 
structure allows for fiiU indepoident control of the devices \mder test 

One advantage of having a bum-in tester that can provide individual control of a device under test is 
5 to ensure that thennal runaway conditions are minimized. That capability, which relies on the software and 
hardware architecture which allows individual control over environmental conditions for each device under 
test The approach to minimizmg thennal runaway conditions is described below. 

A bum-in tester operating according to an embodiment of the present invention picks an operating set 
point at which to test the device xmder test (DUT). The DUT typically remains at that set point for an extended 

10 period of time (e.g., more than 24 hours) as the bum-in tests are nm. If stability is achieved at the outset of 
testing, the device is much more likely to remain stable during testing. As the device under test is powered up 
and testing is begun, its progress towards the selected set point is monitored. For example, tiie rate of change 
of tenq>e]:Bture for the first few minutes of operation can be measured periodically, e.g., every thirty seconds, 
as the device approaches its set point If ^ device is approaching its set point at a rate that indicates a stable 

15 approach, no action needs to be taken by the tester otiier than continued testing. If however, the rate of diange 
of tenq>erature indicates that the device is becoming or likely to become unstable because tiie rate of 
ten:5)erature change is too high, operating parameters of the device under test can be changed and the set point 
approached agaiiL The high temperature characteristics of a part are typically unknown prior to bum-in 
testing, since previous tests are run at increasingly low temperatures. 

20 For exair5)le, assume a rate of change is determined to be too high. In that case, the tester changes 

one of the operating parameters and tries to bring the device under test up to tiie set point for stable operation. 
For exan^le, the tester may lower the frequency being supplied to the device under test In addition to 
reducing frequency, other operating parameters can be varied instead of or in combmation with reducing 
operating frequency. For mstance, the gain of the thermoelectric cooler (TEQ may be increased to atteQq)t to 

25 control the temperature as the DUT approaches the set point' 

In addition, the particular type of test being run or test vectors being applied may affect power 
consun^tion and thus tenq)erature. For exanq)le, if random patterns are being used as test vectors, a test that 
consumes less power, such as a memory test, can be run instead. Such a test exercises fewer circuits in tiie 
device under test and tiius reduces power consumption. Finally, voltage may be reduced m an attenq)t to bring 

30 the DUT to a stable operating point Voltage is typically the last parameter to change because reducing 

voltage also effects the bum-in reliability acceleration. In addition, voltage should not be reduced greater than, 
the field voltage (i.e., the typical operating voltage). In fact, any combination of the above-described operating 
parameters can be utilized to try to bring the device to stable operation at the selected tenq)erature set point. 
Thus, if lowering the frequency of the device under test &ils to achieve stable operation, both lowered 

35 frequency and increased TEC gain may be used to try to approach the set point in a stable manner. If that &ils 
to work, diSerent tests may also be utilized. Finally, voltage may also be lowered. The attenq)ts to approach 
the set point in a stable manner may continue with difTerent combinations of operatii^ parameters until tiie 
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DUT achieves stable opeiatioii at the set point The various hardware and software described herein is 
effective at providing independent control of the devices under test to achieve stable operatioiL 

Thus, the hardware and software of a tester {q)paTatus and method have been described, \^iich 
provides for independent control of the operational and environmental parameters of the devices under test. 
Tbs description of the invention set forth herein is illustrative, and is not intended to limit the scope of the 
invention as set for& in the following claims. Variations and modifications of the embodiments disclosed 
herein^ may be made based on the descr^tion set fortii herein, without departing from the scope and spirit of 
die mvention as set forth in the foUownig claims. 
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WHAT IS CLAIMED IS; 

1 . A bum-in tester con^nising: 
a plurality of test positions; and 

wherein the bum-in tester is operable to independently control tenq>erature of each device under test 
at each test position. 

5 2. The bum-in tester as recited in claim 1 wherein the bum-in tester includes at least one 

independently controllable cooling device per test position, and wherein the at least one cooliog device is one 
of a thermoelectric cooler and a fan. 

3. The bum-in tester as recited in claim 1 wherein the bum-in tester is further operable to 
independently control tests being applied to each device under test at each test position, flie tests including at 

10 least one of automatic test pattern generation (ATPG) test patterns, functional testing, random scan patterns 
applied by the bum-in tester and built in self test (BIST) tests. 

4. The bum-in tester as recited in any of claims 1 through 3 wherein the bum-in tester is further 
operable to independently control voltage being applied to each device under test at each test position using a 
plurality of independently controllable voltage regulator circuits associated with respective ones of the test 

IS positions, each of the voltage regulator circuits supplying a controllable voltage to a respective one of the 
devices under test 

5. The bum-in tester as recited in claim 4 wherein the bum-in tester is operable to 
independently control the operating frequency of each of the devices under test so as to independentiy change 
a frequency of operation of one device under test independentiy of operational frequencies of other devices 

20 under test. 

6. A method of bum-in testing a plurality of integrated circuits comprising: 
simultaneously testmg tiie iutegrated circuits at a respective plurality of test positions; and 
independentiy controlling a testing ten^erature of each of the integrated ckcuits being tested at 

respective ones of the test positions. 

25 7. The method as recited in claim 6 further comprising independentiy controlling an operating 

frequency of at least some of the integrated circuits, thereby allowing at least some of the integrated circmts to 
be simultaneously tested at different frequencies. 

8. The method as recited in any* of claims 6 or 7 further comprising independentiy controlling 
the voltage being supplied to the integrated circuits beiug tested, thereby allowing at least some of tiie 
30 integrated circuits to be simultaneously tested at different voltages. 
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9. The method as recited in claim 8 further conpising changing a test nmning on one of the 
integrated circuits independently of tests being run on others of the integrated circuits. 

10. A bum-in testing apparatus conqirising: 
a plurality of test positions; 

means for controlling ten^erature of an integrated circuit being tested in one of tiie test positions 
independently of temperatures of other integrated circuits being tested in other of the test 

positions; 

means for controlling voltage of an integrated circuit being tested in the one of the test positions 
independently of voltages of other integrated chrcuits being tested in other of the test 
positions; 

means for controlling a test being applied to an integrated circuit being tested in die' one of the test 

positions independently of tests bemg q>plied to other integrated circuits being tested in 

other of the test positions; and 
means for controlling jfrequency of an integrated circuit being tested in the one of the test positions 

independently of frequency of other integrated circuits being tested in other of the test 

positions. 
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